Wi-Fi IoT access mode is one of the most widely applied IoT access modes with lowest cost and best extensibility. Usually, a Wi-Fi IoT device accesses network via a Wi-Fi access point (also called Wi-Fi hotspot or wireless router). If a Wi-Fi IoT device is to access a Wi-Fi access point, it has to obtain a name and a password of the Wi-Fi access point in a certain manner. However, a Wi-Fi IoT device usually does not have a keyboard or display. Thus, it is desired to have a simple, effective, and reliable way to transmit access information of a Wi-Fi access point to a Wi-Fi IoT device.
Existing 802.11n has two frequency range modes: HT20 and HT40. HT20 considers more about compatibility: for example, if 11b/g signals are present in an area, then in order to reduce interference to the signals as much as possible, HT20 mode has to be set, so as to reduce overlap between frequency bands. HT40 considers more about high performance: HT40 is corresponding to a bundle of two HT20 channels, one of which is a primary channel, and the other is a secondary channel. The primary channel sends beacon messages and some data messages, while the secondary channel sends other messages.
Similarly, existing 802.11ac has three frequency range modes: VHT20, VHT40, and VHT80. VHT40 is corresponding to a bundle of two VHT20 channels, while VHT80 is corresponding to a bundle of two VHT40 or four VHT20 channels.
Most Wi-Fi IoT devices have a single or limited functions, and relatively small data exchange volume, so 802.11n/ac IoT devices often only support lower frequency range modes, but do not support higher frequency range modes.
Currently available SmartLink/SmartConfig/SmartConnect technologies include: a mobile phone APP end sends UDP broadcast or multicast packets containing a name and a password of a Wi-Fi access point; a Wi-Fi IoT device may receive a sequence of the UDP packets, and as long as a form of organization of the UDP packet sequence is known, it may obtain the name and the password of the Wi-Fi access point through the received UDP packet sequence. Working principles of such an approach are that a Wi-Fi IoT device uses a Wi-Fi listening mode, parses a MAC address and a MAC layer retransmission flag in a MAC header of the received Wi-Fi communication MAC layer data packet for filtering, and based on a MAC packet length in the MAC header, derives a packet length of a UDP packet sent by the mobile phone. However, in several circumstances as described above, the Wi-Fi IoT device cannot correctly receive the Wi-Fi MAC layer data packet of the UDP packet, and cannot derive information of the data packet, such as MAC address, MAC layer retransmission flag, and MAC layer packet length.
In most circumstances, the Wi-Fi IoT device has to obtain configuration information by demodulating and parsing the whole configuration information packet. If trying to use 802.11n HT40 mode to configure an IoT device which only supports HT20, or use 802.11ac VHT80 mode to configure an IoT device which only supports 802.11ac VHT40 mode, or use 802.11ac VHT80/VHT40 mode to configure an IoT device which only supports 802.11ac VHT20 mode, then the configuration information packets cannot be demodulated. Or, if current channel condition is poor, or the receiving IoT device has MIMO limitation/channel encoding/decoding limitations, etc., causing data portions of the configuration information packets cannot be correctly demodulated, then the device consequently cannot be easily configured.